[CData API Server実践編]AWS環境で本番環境を構築してみる

「カスタマーストーリー」を支えるツール特集

#REST

#Elastic Load Balancing (ELB)

#AWS Auto Scaling

#CData

#Application Load Balancer（ALB）

kobayashi.m

2020.07.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

データアナリティクス事業本部のkobayashiです。

REST API構築ツール CData API Server を下記のエントリにてWindowsの環境やEC2のAmazonLinux2で構築してみました。

これらの手順で簡単にAPIサーバーが構築でき開発やテスト環境としてはこの内容で十分なのですが、いざ本番環境となると

HTTPなため平文でのデータのやり取りになっておりHTTPS化を行う
可用性と耐障害性を向上させる

が必要になってくるかと思います。今回はこの2点を満たし本番環境でCData API Serverが使用に耐え得る環境をElastic Load Balancing（今回はAplication Load Balancerを使用。以下ALB）とAmazon EC2 Auto Scalingを用いて作成します。

なお今回のエントリ内容は以下の記事を参考にさせていただいております。こちらも併せてご覧ください。

AWSとCDataで実現するスケーラブルなWebAPIサーバーの構築手順 - Qiita

環境

Amazon Linux 2
CData API Server - 19.0.7493.0
RDS MariaDB 10.2.21

CData API Serverの本番環境構成

今回作成する構成は以下の図の様になります。

ポイントは以下になります。

CData API ServerのアプリケーションデータをRDSへ保存する
CData API ServerをインストールしたAMIを作成しAuto Scalingの起動テンプレートを作成する
HTTPS化を行うためにAWS Certificate Managerで独自ドメイン用の証明書を発行しALBで使用する
ALBをAuto Scalingグループ（AMIを使った起動テンプレート）にアタッチする

ALBで証明書を使うことになり外部からALBまではHTTPS化した通信が行えセキュアになります。また CData API Serverのアプリデータを個々のインスタンス内ではなく外部のRDSへ保存することで起動したインスタンスから共通のデータを使うことになりAuto Scalingでスケーリングが可能になります。

実際の作業は以下の手順で行います。

ALB、Auto Scaling Group、RDSで使うセキュリティグループを作成する
アプリデータを保存するRDSを作成する
CData API ServerをインストールしたAMIを作成する
ACMで証明書を発行する
ロードバランサー（ALB）を作成する
Auto Scaling Groupを作成する

1. ALB、Auto Scaling Group、RDSで使うセキュリティグループを作成する

これから行う設定で３種類のセキュリティグループが必要なので予め作成しておきます。

作成するセキュリティーグループはALB用、Auto Scaling Group用、RDS用の順番で作成します。

手順1-1). AWSマネージメントコンソールでEC2の画面へ進み、サイドバーのネットワーク＆セキュリティ > セキュリティグループと進み、セキュリティグループを作成を押下して作成画面へ進む。

手順1-2). ALB用のセキュリティグループを作成するため以下の内容を設定しセキュリティグループを作成を押下しセキュリティーグループを作成する。

セキュリティグループ名 : 適切な名前を入力
説明 : 適切な内容を入力
VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
インバウンドルール : ルールを追加を押下し以下のルールを追加

タイプ	プロトコル	ポート範囲	ソース
HTTPS	TCP	443	0.0.0.0/0

手順1-3). 手順1-2と同じ作業でAuto Scaling Group用のセキュリティグループを作成するため以下の内容を設定しセキュリティグループを作成を押下しセキュリティーグループを作成する。

セキュリティグループ名 : 適切な名前を入力
説明 : 適切な内容を入力
VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
インバウンドルール : ルールを追加を押下し以下のルールを追加

タイプ	プロトコル	ポート範囲	ソース
カスタムTCP	TCP	8080	（先に作成したALB用のセキュリティーグループID）
カスタムTCP	TCP	8080	（CDataをインストールする端末のIPアドレス）
SSH	TCP	22	（CDataをインストールする端末のIPアドレス）

手順1-4). 手順1-2と同じ作業でRDS用のセキュリティグループを作成するため以下の内容を設定しセキュリティグループを作成を押下しセキュリティーグループを作成する。

セキュリティグループ名 : 適切な名前を入力
説明 : 適切な内容を入力
VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
インバウンドルール : ルールを追加を押下し以下のルールを追加

タイプ	プロトコル	ポート範囲	ソース
MYSQL/Aurora	TCP	3306	（先に作成したAuto Scaling Group用のセキュリティーグループID）

以上でセキュリティグループの作成が終わります。

2. アプリデータを保存するRDSを作成する

次にCData API Serverで作成されるログデータやユーザーデータなどを保存するRDSを作成します。今回は自分が使い慣れていることもありMariaDBを選択しましたがMySQLでも問題ありません。ただCData API Serverの標準ドライバで接続できるデータベースが良いと思うのでRDSでしたらMariaDBかMySQL、AuroraでしたらMySQL との互換性を持つ Amazon Auroraを使うのが無難です。

手順2-1). AWSマネージメントコンソールでRDSの画面へ進み、サイドバーのデータベースを押下しデータベースの作成を押下し設定画面に進む手順2-2). データベースの作成画面に遷移するので設定を行いデータベースの作成を押下しデータベースを作成する。

データベース作成方法を選択 : 標準作成を選択
エンジンのオプション
- エンジンのタイプ: MariaDBを選択
- バージョン : MariaDB 10.2.21を選択
テンプレート : 運用に適切なものを選択（試しに行うなら無料利用枠を選択します）
設定 :
- DBインスタンス識別子 : 適切な文字列を入力（接続先名になります）
- 認証情報の設定 : 適切な情報を入力（後に接続席情報で使います）
DBインスタンスサイズ : 適切なものを選択（試しに行うならdb.t2.microを選択）
ストレージ : 適切な設定を入力（試しに行うならデフォルトの設定で問題なし）
接続
- VPC : ALB、Auto Scaling Group、RDSを作成するVPCを選択
- サブネットグループ : 適切なものを選択
- パブリックアクセス可能 : なし
- VPCセキュリティグループ : 手順1-4で作成したセキュリティグループ
- アベイラビリティーゾーン : 適切なものを選択
- データベースポート : 3306

他の設定値はデフォルトのままにします。

3. CData API ServerをインストールしたAMIを作成する

インストールは以前のエントリにてまとめてありますのでそちらをご確認ください。

このエントリの続きから作業を行います。なお上記のエントリでライセンスについて詳しく解説を行いませんでしたが、AMIを作成してオートスケールを行うにはマシンIDをチェックしないライセンスが必要になりCData API Serverのライセンスには「CLOUDライセンス」が必要になります。

また標準のデータソース（SQLite、Apache Derby、MySQL、Excel）以外のデータソースを扱いたい場合は別途CData社のドライバが必要になります。その際にもマシンIDをチェックしないライセンスとしてJDBC URL にRTK（RunTimeKey）プロパティを設定する必要があり、RTKライセンスが必要になります。

手順3-1). CData API Serverへログインし、ヘッダーメニューから情報へ進み、新しいライセンスで押下しライセンス情報を入力する。その際に必ず「CLOUDライセンス」を購入して入力する。

手順3-2). 設定 > 接続と進み標準以外のドライバでRTKライセンスを入力したい接続を選択する。

手順3-3). Advancedタグを選択しOtherのセクションまで進むとRTK :の項目があるのでRTKライセンスキーを入力し、接続チェックを行い接続が確認できたら変更を保存で設定を保存する。

これでCData API Serverに関する設定は終わったのでこのインスタンスのイメージを作成してAuto Scalingで使います。

手順3-3). サイドバーのインスタンスからインスタンス一覧を表示し、イメージを作成したいEC2インスタンスを選択する。アクション > イメージ > イメージの作成と進みAMI作成モーダルを立ち上げる。

手順3-4). イメージ名にわかりやすい名前を入力し、イメージの作成を押下してイメージを作成する。

これでAuto Scalingで使用するAMIは作成できました。

4. ACMで証明書を発行する

次にHTTPS化を行うためALBに独自ドメイン用のSSL証明書を使いますがACMで発行します。その際に必要な独自ドメインはRoute53で管理されているとACMでの証明書発行が簡単です。今回はすでにドメインは取得済みでRoute53で管理されていることを前提としてACMでSSL証明書を発行する方法をまとめます。

手順4-1). AWSマネージメントコンソールでCertification Managerの画面へ進み、証明書のリクエストを押下し証明書のリクエストへ進む。

手順4-2). パブリック証明書のリクエストを選択し、証明書のリクエストを押下して先へ進む。

手順4-3). ドメイン名の追加画面でドメイン名の欄に設定したいドメインを入力し次へを押下し進む。

手順4-4). 検証方法の選択画面に遷移するのでRoute53でドメインを管理しているならDNSの検証を選択する。

手順4-5). Route 53でドメインを管理しているのでRoute 53でのレコードの作成をクリックする。（＊もしRoute 53以外でドメインを管理している場合は個別にCNAMEを設定して下さい。）

手順4-6). 設定するRoute 53のホストゾーンとレコードの内容を確認後、作成を押下する。

以上でACMでSSL証明書の発行の設定が終わります。しばらくするとドメインの検証が終わりACMのダッシュボードの画面で状況が発行済となればSSL証明書が使えるようになります。

5. ロードバランサー（ALB）を作成する

次にロードバランサーとしてALBを設定します。

手順5−1). AWSマネージメントコンソールでEC2の画面へ進み、サイドバーのロードバランシング > ロードバランサーと進み、ロードバランサーの作成を押下して作成画面へ進む。

手順5-2). ロードバランサーの種類の選択画面にてApplication Load Balancerの作成を押下する。

手順5-3). ロードバランサーの設定画面に進むので必要情報を入力し、セキュリティ設定の構成を押下して先へ進む。

名前 : わかりやすい名前を入力
スキーム : インターネット向けを選択
IPアドレスタイプ : ipv4を選択
リスナー − ロードバランサーのプロトコル : HTTPSを選択
- ロードバランサーのポート : 443を入力
アベイラビリティーゾーン :
- VPC : 適切なVPCを選択
- アベイラビリティーゾーン : 可用性を高めるために2つ以上選択

手順5-4). セキュリティ設定の構成へ進むので証明書タイプでACM から証明書を選択する (推奨)を選択し、証明書の名前で手順4で設定した証明書の名前を選択する。セキュリティポリシーはデフォルトのままにし、セキュリティグループの設定を押下して先へ進む。

手順5-5). セキュリティグループの設定画面に進むのでセキュリティグループの割当で既存のセキュリティグループを選択するを選択し、手順1−2で作成したセキュリティグループを選択し、ルーティングの設定を押下し先へ進む。

手順5-6). ルーティングの設定画面に進むので設定を行い、ターゲットの登録を押下する。

ターゲットグループ
- ターゲットグループ : 新しいターゲットグループを選択
- 名前 : わかりやすい名前を入力 − ターゲットの種類 : インスタンスを選択 − プロトコル : HTTPを選択
- ポート : 8080を入力 − ヘルクチェック − プロトコル : HTTPを選択
- パス : /login.rstを入力

他はデフォルト値で問題ありません。パスですが/ですとCData API Server側でリダイレクトが設定されているため303が返りヘルスチェックでunhealthyとなってしまうので注意してください。

手順5-7). ターゲットの登録画面に進みますが後の手順でAuto Scalingグループを設定するのでここでは何も設定せず進む。

以上でALBの設定が終わり、ALBとターゲットグループが作成されます。

6. Auto Scaling Groupを作成する

最後ににALBで使うAuto Scaling GroupをCData API ServerをインストールしたAMIを使ってインスタンスを起動するように作成します。

はじめに起動テンプレートを作成します。

手順6-1). AWSマネージメントコンソールでEC2の画面へ進み、サイドバーのインスタンス > 起動テンプレートと進み、起動テンプレートを作成を押下して作成画面へ進む。

手順6-2). 起動テンプレートを作成画面に進むので設定の中でAuto Scalingのガイダンスにチェックを入れ設定を行う。起動テンプレートを作成を押下する。

起動テンプレート名 : わかりやすい名前を入力 − Auto Scalingのガイダンス : チェック
AMI : 手順3で作成したAMIを選択 − セキュリティグループ : 手順1-3で作成したセキュリティグループを選択

他はデフォルト値で問題ありません。

以上で起動テンプレートが作成されるので次にAuto Scaling Groupを作成します。

手順6-3). サイドバーのAuto Scaling > Auto Scalingグループと進み、Auto Scalingグループを作成するを押下して作成画面へ進む。

手順6-4). 起動テンプレート作成の画面へ進むので、Auto Scalingグループ名にわかりやすい名前を入力し、起動テンプレートで手順5−2で作成した起動テンプレートを選択する。

手順6-5). 設定の構成へ進むので、購入オプションとインスタンスタイプでは運用に併せてインスタンスの分散とインスタンスタイプを設定する。

ネットワーク
- VPC : 適切なVPCを選択
- サブネット : 可用性を高めるために2つ以上選択(手順5−3で設定したALBと同一にする)

手順6-6). 詳細オプションを設定の画面に進むので設定を行い次へを押下する。

ロードバランシング : ロードバランシングの有効化をチェックし、Application Load Balancer または Network Load Balancerを選択
ロードバランサーのターゲットグループを選択 : 手順5−6で設定したロードバランサーのターゲットグループを選択
ヘルスチェック : ELBをチェック
モニタリング : CloudWatch 内でグループメトリクスの収集を有効にするをチェック

手順6-7). グループサイズとスケーリングポリシーを設定する画面に進むので、ここも運用に併せてグループサイズ、スケーリングポリシー、スケールイン保護を設定する。次の通知の設定、タグの設定も運用に併せて設定する。

以上でAuto Scaling Groupが作成されます。グループサイズやスケーリングポリシーは運用を行っていく中で最適値がわかると思いますのでその都度設定を変更していけば良いと思います。

ここまでの設定で最初に示した本番環境の構成が出来上がりです。設定が終わってしばらくするとインスタンスが立ち上がりターゲットグループでターゲットを確認するとhealthyになります。

この状態になればALB経由でアクセスできるようになるので実際にアクセスして確かめて見たいと思います。

確認

実際に出来上がった環境でリクエストを送り正しいレスポンスが返ってくるかを確認します。なおテストのためALB配下のインスタンスはスケールアウトして3台起動した状態でテストしてみます。

管理画面の確認

ALBで設定したSSL証明書のドメインでアクセスしてみます。

直接CData API ServerをインストールしたEC2にアクセスするのと変わりなくログイン画面が表示されます。またALBにSSL証明書を設定したのでhttpsでアクセスできているので暗号化もできています。

AMI作成時に設定した管理者アカウントでも問題なくログインできます。

またリソース、接続先、ユーザーなども共有できています。

リクエストとレスポンスの確認

開発環境ですとEC2のアドレスを使用して直接インスタンスにリクエストを送っていましたが、リクエストの送信先もALBに向けます。

リクエスト1

curl --header "x-cdata-authtoken: MY_AUTH_TOKEN" "https://{独自ドメイン}/api.rsc/world_country/"

レスポンス1

{
  "@odata.context": "https://{独自ドメイン}/api.rsc/$metadata#world_country",
  "value": [
    {
      "Code": "ABW",
      "Capital": 129,
      "Code2": "AW",
      "Continent": "North America",
      "GNP": 828.00,
      "GNPOld": 793.00,
      "GovernmentForm": "Nonmetropolitan Territory of The Netherlands",
      "HeadOfState": "Beatrix",
      "LifeExpectancy": 78.4,
      "LocalName": "Aruba",
      "Name": "Aruba",
      "Population": 103000,
      "Region": "Caribbean",
      "SurfaceArea": 193.00,
      "IndepYear": null
    },
    {
      "Code": "AFG",
      "Capital": 1,
      "Code2": "AF",
      "Continent": "Asia",
      "GNP": 5976.00,
      "GovernmentForm": "Islamic Emirate",
      "HeadOfState": "Mohammad Omar",
      "IndepYear": 1919,
      "LifeExpectancy": 45.9,
      "LocalName": "Afganistan/Afqanestan",
      "Name": "Afghanistan",
      "Population": 22720000,
      "Region": "Southern and Central Asia",
      "SurfaceArea": 652090.00,
      "GNPOld": null
    },
    {
      "Code": "AGO",
      "Capital": 56,
      "Code2": "AO",
      "Continent": "Africa",
      "GNP": 6648.00,
      "GNPOld": 7984.00,
      "GovernmentForm": "Republic",
      "HeadOfState": "José Eduardo dos Santos",
      "IndepYear": 1975,
      "LifeExpectancy": 38.3,
      "LocalName": "Angola",
      "Name": "Angola",
      "Population": 12878000,
      "Region": "Central Africa",
      "SurfaceArea": 1246700.00
    },
 ...
  ]
}

今までと変わりなく問題なくレスポンスが返ってきます。